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SWITCHED CONNECTIONS DIAGNOSTICS IN A SIGNALLING NETWORK 
This invention relates to the field of digital networks, for example, 
asynchronous transfer mode (ATM) networks and, more particularly, to a methodology 
for detecting and diagnosing switched connection failures in a signaling network when 
5 attempting to setup a call. 

Network switches, controlled by signaling software, can dynamically setup 
end-to-end connections across the network, for instance, Switched Virtual Channel (SVC) 
or Soft Permanent Virtual Channel (SPVC) connections in an ATM network. Sometimes 
these connections fail to route successfully. 
10 Today's signaling software provides very simple cause and diagnostics 

information to aid in trouble shooting failed call attempts. Often, the cause and 
diagnostics are inadequate to trouble shoot the root cause of the problem as only a single 
reason is provided as to the failure. Much manual work, often involving more than one 
operations person, must be done to actually locate the root cause of the problem. This 
15 becomes very costly in terms of network resources and time. 

More detailed connection diagnostics are required to aid in troubleshooting in 
these situations. 

An object of the present invention is to alleviate the prior art problem. 

According to the present invention there is provided a method of diagnosing 
20 faults in a network having a plurality of nodes through which switched virtual 
connections can be established, comprising the steps of recording all attempts at 
establishing routes through the network; and analyzing the attempted routes to identify the 
source of a failure. 

The switched connection diagnostics functionality, embodying the present 
25 invention, collects details in call processing messages for each switch and physical trunk 
visited plus rejection causes for every attempted route during the call setup phase. The 
collected information is returned in the call processing messages back to the source 
switch which in turn presents this information to network operators. These details enable 
the network operators to easily isolate and troubleshoot problems. 
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This invention enables signaling software to gather detailed information for a 
switched connection for every leg of a call setup rather than simply providing one reason 
as to routing failure, thus allowing quick problem resolutions with minimal effort. 

The invention also provides a packet switched data communications network, 
5 comprising a plurality of interconnected network nodes; a plurality of users connected to 
at least some of said network nodes; means for attempting to establish virtual connections 
between users over a plurality of alternate routes through said network; and means for 
recording, in a diagnostic mode, attempts at establishing routes through said network; and 
diagnostic means for analyzing said recorded attempts to identify the source of a failure. 
1 0 The invention will now be described in more detail, by way of example, with 

reference to the accompanying drawings, in which: 

Figure 1 illustrates a communications network capable of establishing 
switched virtual connections; 

Figure 2 illustrates diagnostics points of failure between two network 

15 switches; 

Figure 3 illustrates diagnostics operation for a call trace of a successful call; 
Figure 4 illustrates diagnostics operation for a call trace of a successful call 

with one node failure; and 

Figure 5 illustrates diagnostics operation for a call trace of an unsuccessful 

20 call. 

In Figure I , tgXY, where X, Y can be a node A, B, C, D, E represents a trunk 
group from the node X to the node Y and uX represents a user, i.e. a service subscriber, 
for a user network interface (UNI) at the node X.. The nodes represented by the letters A 
to E are typical switches, such as, Newbridge Networks Corporation's 36170 switches. 

25 For example, tgAB is the trunk group between switches A and B while uA and uD are 
users for the UNIs at respective nodes A and D. 

A switched virtual channel (SVC) connection can be setup from Customer 
Premise Equipment 1 (CPE-1) to Customer Premise Equipment 2 (CPE-2) using users uA 
and uD for the calling and called addresses, respectively. Alternatively, a soft permanent 

30 virtual channel (SPVC) connection can be setup from the port on A where CPE-1 is 
attached at uA to the port on D where CPE-2 is attached at uD. If a routing problems 
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occurs with either the SVC or SPVC connection setups, then the following steps should 
be taken to diagnose the problem depending on the type of connection. 
SVC Case: 

A customer at CPE-1 complains that its application is not functioning. The 
5 Service Provider turns on or activates the switched connection diagnostics for user uA, 
and instructs the customer to try the application again. The SVC connection setup is 
retried and switched connection diagnostics are collected. The results from the 
diagnostics are analyzed. By using the routing reject points, the Service Provider can 
locate and then correct the problem in the network. The Customer retries his application 
10 and is once again back in service. 

SPVC Path Case #1 - Path is Waiting For Resources: 

The Service Provider configures an SPVC path from user uA to user uD, and 
connects it. The path setup enters a Waiting for Resources state. The Service Provider 
initiates the switched connection diagnostics for the specific problematic SPVC path. 
15 The SPVC path is retried and switched connection diagnostics are collected. The results 
from the diagnostics are analyzed. By using the routing reject points, the Service Provider 
can locate and then correct the problem in the network. The SPVC path is retried. The 
call is completed and now enters the connected state. 

SPVC Path Case #2 - Path is Connected: 
20 The Service Provider configures an SPVC path from user uA to user uD, and 

connects it. The path enters the connected state. The Service Provider desires to 
determine the reason why the path took the route it did. The Service Provider initiates the 
switched connection diagnostics for the specific SPVC path. 

A bridge and roll optimize operation is performed on the path in order to 
25 gather switched connection diagnostics for the path. International application 

PCT/CA97/00507, filed July 17,1997, describes an implementation of the bridge and roll 
operation. This operation may be service affecting. However, if it is completed close to 
the instance at which the path was first connected, there is a high probability that a more 
optimal route does not exist. The results are analyzed and routing reject points can then 
30 be further investigated to discern the cause of the path's present routing. 
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For a specific example of an application of the switched connection 
diagnostics, assume each switch has routing tables allowing uA to route an SVC to uD, 
and assume tgCD has no remaining bandwidth for the SVC. The SVC would start from 
A, use tgAB (assume primary trunk group) to get to B, then proceed to use tgBC to get to 
C. Once at C, routing determines that tgCD is full and cranks back to B. B then cranks 
back to A as there are no other routes from B to D. A crankback occurs when a node 
passes a call back to a previous node because it is unable to establish an onward 
connection. From A, the alternate trunk group tgAE is used. From E, tgEC is used, and 
again at C, routing determines tgCD is full and cranks back to E. E then cranks back to A 
as there are no other routes from E to D. Now A has exhausted its routes so the SVC is 
released back to CPE 1 . 

Switched connection diagnostics record all routes attempted, i.e. A, tgAB, B, 
tgBC, C, reject reasons (cause and diagnostics), A, tgAE, E, tgEC, C, reject reasons. If 
this list is followed, it can be determined that all roads lead to C, but there is NO usable 
route from C to D. The next step in the procedure is to focus diagnostics efforts at C to 
determine why tgCD is not usable. 

Having regard specifically to SVC switched connection diagnostics, SVCs are 
setup from user terminal to user terminal across the network. The point of attachment 
into the network from the user terminal defines the entry and exit points for the SVC. 
The point of attachment is defined by a Call Processing User and its physical access i.e. 
its Trunk Group and the controlling signalling link. The switch routes an SVC from the 
User at the entry point to the User at the exit point. Routing tables, either static or 
dynamic, present in each node steer SVC setup messages from the source User to the 
destination User. When routing chooses a route, i.e. a trunk group, the signalling message 
is sent out on the signalling link controlling the trunk group. 

For SVCs, switched connection diagnostics are provided on a per User basis, 
and may be turned on (activated) or off (de-activated). The default for diagnostics is off. 
awaiting activation. 

Every calling User that originates an SVC when switched connection 
diagnostics are activated will gather diagnostics information during call setup. This 
enables an end-user application to startup. The end-user has the opportunity to signal 
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potentially more than one SVC, and diagnostics will gather information on all SVCs 
originated from the application. 

If diagnostics are not de-activated for a User after an SVC routing problem 
has been diagnosed, then call setup performance for the User will be degraded as 
5 unwanted diagnostic information is collected for every call on the User. To guard against 
inadvertently leaving switched connection diagnostics active, the diagnostics are gathered 
for a predetermined number of connection setups, for example the first 10 SVCs/SPVC 
paths setup for the User. After 10 calls for the User, the switched connection diagnostics 
de-activates itself. 

10 If switched connection diagnostics are active for a User, and that User is the 

destination of a call, there is no effect. Switched connection diagnostics applies only to 
calls originated by a User. 

In the case of SPVC switched connection diagnostics, the SPVC path , 
definition contains the source, destination and administrative information for connection 

15 setup. The SPVC connection setup procedure initiates an SVC from the source endpoint 
towards the destination endpoint, and therefor uses the same routing procedures as SVCs. 
In one reference model, the SPVC path endpoints are the ports on the switch where the 
customer premise equipment (CPEs) are attached. The Users, i.e. uA and uD, plus port 
and endpoint information define the endpoints for the SPVC path. Again, routing uses 

20 routing tables, either static or dynamic, present in each node to steer SPVC setup 
messages from the source User to the destination User. 

Switched connection diagnostics are provided on a per SPVC path basis, and 
may be turned on or off for the next SPVC path setup attempt. By default, the diagnostics 
are off. Once switched connection diagnostics have been turned on for an SPVC path, the 

25 next time the SPVC path is setup, diagnostics information are collected for that SPVC. 

When an SVC or SPVC call is being setup, routing attempts to route the call 
from source to destination. It uses loop detection and crankback optimizations to route 
the call. In this process, many different routes may be attempted. For every route tried, 
each switch and trunk group traversed is recorded. When a route is rejected, the reason is 
30 also recorded. A node management (Node Management Terminal Interface or NMTI) or 
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network management system can interpret this information to illustrate the routing points 
of failure. 

Depending on the circumstances, switched diagnostics may provide more 
information when employed with hop-by-hop routing to setup a call, in comparison to 
5 source routing for call setup. A particular source routing technique is Private Network 
Node Interface (PNNI), wherein routing tables are regenerated and distributed to all nodes 
running PNNI. If a node becomes isolated because the physical access to it fails, then all 
routes to the isolated node are removed from all routing tables. For example, in Figure 1, 
if node D goes off-line, then all routing tables (at nodes A, B, C and E) will not have an 
1 0 entry for the Users on node D. Therefore, the routing of an S VC or SP VC path from uA 
to uD will fail at node A and never leaves the node. The switched connection diagnostics 
information will contain node A, and a cause indicating that the destination is 
unreachable; Otherwise, if the routing tables are static hop-by-hop, much more diagnostic 
information typically would be gathered as routing attempts to use all configured routes 
1 5 that lead to D. All cause codes recorded at C will indicate that resources are unavailable. 

Turning to Figure 2, illustrated is an exemplary signalling message exchange 
between two call control entities of respective network switches in order to setup a call. 
On the Newbridge 36170 switch, service cards perform the call control and signalling 
functions depicted. When routing chooses a trunk group, an SVC/SPVC setup request is 
20 forwarded out the signalling link that controls the trunk group. Figure 2 illustrates the 
scenarios that can result between the switches: 

1. Call control forwards the setup message to the local signalling stack. 

2. The local signalling stack rejects the message and returns failure to local 

call control. 

25 3 . The local signalling stack forwards the setup message to the remote 

signalling stack. The remote signalling rejects the setup message and informs the local 
signalling stack of the rejection. The remote Call Control engine is not informed 
whatsoever. 

4. Remote call control software in the switch on the remote side of the 
30 signalling link receives the SVC/SPVC setup message and processes it. 



BNSDOCID: <WO 9833351 A1 > 



WO 98/33351 



-7- 



PCT/CA98/00029 



The first and fourth scenarios are processed by call control which logs 
diagnostics at this level. However, if scenarios two or three occur, then the diagnostic 
information must reflect this. If the local end rejects the call, then perhaps the service • 
card servicing the signalling link is overburdened. If the remote end rejects the call, then 
5 perhaps the service card at the remote end is overburdened. This information pin-points 
perhaps a troubled service card. 

Diagnostics are collected on a per service card basis. The service card, that 
manages the SVC User and SPVC path, collects switched connection diagnostics 
information when diagnostics is enabled. The service card can store switched connection 
10 diagnostics information for a predetermined number, say only 50 SVC or SPVC path 

setup attempts. The 50 most recent setup attempts are stored. This should be sufficient to 
allow several external network management requests to initiate switched connection 
diagnostics requests, then subsequently collect the results. 

The enhanced signalling used to carry diagnostics information will now be 
15 described in more detail. Enhanced signalling is achieved by using information elements 
(IEs) defined to be in "Codeset 6", information elements specific to the local network. 

The ITU-T Q.293 1 signalling specification standardized coding format for 
information elements is followed. Therefore, all information elements contain an 
Information Element Identifier, Length and Instruction fields as shown below. 
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The contents of the IE instruction field are always coded with a Flag of 
'follow explicit instructions' and an IE Action Indicator of 'discard information element 
and proceed'. 

New information element identifiers are allocated so as to not collide with 
5 "Codeset 0" identifiers. Codeset 6 information elements are preceded in a message by a 
Broadband Locking Shift information element. Non locking shift procedures are not 
supported. 
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Broadband Locking Shift IE Identifier 
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0 0 
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Length of Broadband Locking Shift IE 


3 


Length of Broadband Locking Shift IE (continued) 


4 


1 


0 0 
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1 1 0 


5 


Ext 


Spare 




Codeset Identifier 





10 The purpose of the Locking Shift information element is to indicate the new 

active Codeset of succeeding information elements. The specified Codeset remains active 
until another locking shift is encountered indicating the new active Codeset. Coding 
Standard (octet 2) is used to indicate ITU-T standardized coding. The Flag (octet 2) 
indicates to follow explicit instructions of the action indicator. The IE action indicator 

1 5 (octet 2) indicates to discard information element and proceed. The Codeset Identifier 
(octet 5) identifies the Codeset, in this case Codeset 6. 

Coding Rules as specified by the ITU-T and ATM Forum are followed. The 
following Table specifies information elements used for enhanced signalling. The 
identifier, maximum length and maximum number of occurrences are given for each 

20 information element. 
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Bits 


Information Element 


Max Length 
(Bytes) 


Max no of 
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8 
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2 
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0 


0 
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0 
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Call Trace 


1476 


1 


0 


1 


1 
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0 
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0 


1 


Broadband locking shift 


5 


1 



There are four particular messages which are used for enhanced signalling 
procedures: Connect, Setup, Release, and Release Complete messages. Each can include 
5 the Broadband Locking Shift information element, followed by a Call Trace information 
element which may have a length ranging from 20 to 1476 octets. Details of the Call 

Trace IE a given below. 

A Connect message is used to return call trace information to the originating 
node on a Successful call completion. Both the Release and the Release Complete 
1 0 messages are used to transfer the reason for a routing failure. Information about the 

routing failure can be carried in either a Cause information element or optionally the Call 
Trace information element. Only the cause of the routing failure is carried in the Cause 
IE whereas the Call Trace IE carries complete information. The Setup message is used to 
collect call tracing information inside the call trace IE as the message traverses the 
1 5 network. 

The purpose of the Call Trace IE is to trace the progress of a call as it 
traverses the network. The information relating to the node address, port and rejection 
causes is collected, as well as failure reasons and extra diagnostic information. The Call 
Trace IE contents form an ordered list representing node traversal information in 
20 chronological order. Each asterisked octet group represents a sub-structure and may be 
repeated in the Call Trace IE, 0 or more times while appearing in any order. 
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0 
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0 
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Length of Call Trace IE (continued) 
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Call Blocked Information 
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Call Completed Indication 
Call Completed Information 



0 
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1 



4 
5* 

5.1* etc. 
6* 

6.1* etc. 
7* 

7.1* etc. 
8* 

8.1* etc. 



10 



Each Call Trace IE is comprised of four components: Call Transited 
Indication, Call Blocked Indication, Call Blocked After Transit Indication, and Call 
Completed Indication. Each of the aforementioned components has a common structure. 
This structure consists of the component identifier, the length of the structure, and the 
component data. 

The Call Transited Indication (octet group 5 of Call Trace IE) denotes the 
successful traversal of a single node in the network. As shown in the format below, both 
node and port information are included. 
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0 0 0 0 0 0 
Call Transited Indication 



Length 



0 0 
Reserved 



0 0 1 
Slot Format 
Identifier 



0 0 1 
Address Identifier 



PCT/CA98/O0O29 

Octet 

5.1 

5.2 
5.3 



Domain 



Domain (continued) 



Major Node Number 



Major Node Number (continued) 



Inbound Slot Number 



Inbound Slot Number (continued) 



Inbound Port Number 



Inbound Sub-Port 



Inbound Sub-Port (continued) 



0 0 
Reserved 



0 



Outbound Selection 
Type 



0/1 
Flag 



Outbound Slot Number 



Outbound Slot Number (continued) 



Outbound Port Number 



Outbound Sub-Port 



Outbound Sub-Port (continued) 
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5.12 

5.13 

5.14 
5.15 
5.16 
5.17 
5.18 



The following list details the individual fields of the Call Transited Indication 
sub-structure: 

• Call Transited Indication (octet 5.1)- This field identifies the component 
type of the sub-structure, i.e., a route success indicator. 

• Length (octet 5.2) - The length of the sub-structure is defined as the length 
of the entire sub-structure less the length and sub-structure identifier fields. 
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• Reserved (octets 5.3 and 5.13) - The reserved fields are ignored on receipt 
and coded as zero when added to the information element. 

• Slot Format Identifier (octet 5.3) - The format of the inbound and outbound 
slots are specified by this field. For example "001" defines a 16-bit slot number 

5 consisting of an 1 1-bit shelf number and a 5-bit slot number. 

• Address Identifier (octet 5.3) - The Address Identifier indicates the type of 
node address that follows. For example "001" represents a Newbridge specific Control 
Packet Switching System (CPSS) address. Bit pattern "010" represents a Point Code. If 
the Address Identifier indicates a Point Code, the domain and major node number are 

1 0 replaced by a 22-octet binary number identifying the point code. 

. Domain (octets 5.4-5.5) - This field defines the domain part of the CPSS 

address. 

. Major Node Number (octets 5.6-5.7) - This field defines the major node 

number of the CPSS address. 
15 . Slot Numbers (octets 5.8-5.9 and 5.14-5.15) - The first octet pair defines 

the ingress slot number of the call, and the second octet pair defines the egress slot 

number of the call. 

• Port Numbers (octets 5. 1 0 and 5. 1 6) - The respective fields identify the 

ingress and egress port numbers of the call. 
20 . Sub-Port Number (octets 5.11-5.12 and 5.17-5.18) - The respective octet 

pair fields identify the inbound and outbound sub-ports. The interpretation of these fields 
are protocol dependent. For cell relay based protocols, the Sub-Port Number fields define 
the Virtual Path Identifier. The first octet pair defines the ingress virtual path of the call, 
and the second octet pair defines the egress virtual path of the call. 
25 . Selection Type (octet 5.13) - This field identifies the outbound port/sub- 

port selection type as being either "001" which represents the preferred route or "010" 
which represents the primary alternate route. 

• Flag (octets 5.13)- This field indicates an Assigning (' 1 ') or Non- 
Assigning ('0') interface. 
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The Call Blocked Indication (octet group 6 of Call Trace IE) denotes the 
failure of a call to traverse a single node in the network. The sub-structure includes node 
and port information, the ingress port/sub-port as well as the reason for call blockage. 



8 
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The following list details the specific fields of the Call Blocked Indication 
sub-structure: 

• Call Blocked Indication (octet 6.1) - This field identifies the component 
type of the sub-structure, i.e., a call blocked opcode. 
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• Length (octet 6.2) - The length of the sub-structure is defined as the length 
of the entire sub-structure less the length and sub-structure identifier fields. 

• Reserved (octet 6.3) - The reserved field is ignored on receipt and coded as 
zero when added to the information element. 

5 • Slot Format Identifier (octet 6.3) - The format of the inbound slot is 

specified by this field. For example "001" defines a 16-bit slot number consisting of an 
1 1 -bit shelf number and a 5 -bit slot number. 

• Address Identifier (octet 6.3) - The Address Identifier indicates the type of 
node address that follows. For example "001" represents a Newbridge specific Control 

10 Packet Switching System (CPSS) address. Bit pattern "010" represents a Point Code. If 
the Address Identifier indicates a Point Code, the domain and major node number are 
replaced by a 22-octet binary number identifying the point code. 

• Domain (octets 6.4-6.5) - This field defines the domain part of the CPSS 

address. 

15 • Major Node Number (octets 6.6-6.7) - This field defines the major node 

number of the CPSS address. 

• Slot Number (octets 6.8-6.9) - The octet pair defines the ingress slot 

number of the call. 

• Port Number (octet 6.10) - This field identifies the ingress port number of 

20 the call. 

• Sub-Port Number (octets 6.1 1-6.12) - This octet pair field identifies the 
inbound sub-port. The interpretation of this field is protocol dependent. For cell relay 
based protocols, the field defines the Virtual Path" Identifier and the octet pair identifies 
the ingress virtual path of the call. 

25 ♦ Cause Value (octet 6.13) - The standard cause values are defined in 

Q.2610. Theses values define the reason for the routing failure. The cause value is 
associated with the port that has been most recently traversed. 

• Diagnostics Cause Value (octets 6. 1 4 and 6.15)- This field stores user 
defined (i.e., proprietary) cause values to aid network diagnostics. 
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• Length of Diagnostics (octet 6.16) - This defines the length of the 
Diagnostics field. 

• Diagnostics (octet 6.17 etc.) - This field contains diagnostic information 
added to the sub-structure to aid in locating the network failures. 

The Call Blocked After Transit Indication (octet group 7 of Call Trace IE) 
denotes a failure of a call to traverse a single node in the network. The sub-structure 
includes node and port information. In addition, incoming and outgoing port/sub-port 
(VPI) may be present. The Call Blocked After Transit Indication always contains 
information to indicate the cause of the route failure at that point in the network. 
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The following list details the specific fields of the Call Blocked After Transit 



Indication sub-structure: 
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. Call Blocked After Transit Indication (octet 7.1)- This field identifies the 
component type of the sub-structure, e.g., a call block after transit opcode. 

• Length (octet 7.2) - The length of the sub-structure is defined as the length 
of the entire sub-structure less the length and sub-structure identifier fields. 

5 • Reserved (octet 7.3) - The reserved fields are ignored on receipt and coded 

as zero when added to the information element. 

• Slot Format Identifier (octet 7.3) - The format of the inbound and outbound 
slots are specified by this field. For example "001" defines a 16-bit slot number 
consisting of an 1 1 -bit shelf number and a 5-bit slot number. 

10 . Address Identifier (octet 7.3) - The Address Identifier indicates the type of 

node address that follows. For example "001 " represents a Newbridge specific Control 
Packet Switching System (CPSS) address. Bit pattern "010" represents a Point Code. If 
the Address Identifier indicates a Point Code, the domain and major node number are 
replaced by a 22-octet binary number identifying the point code. 

! 5 . Domain (octets 7.4-7.5) - This field defines the domain part of the CPSS 

address. 

• Major Node Number (octets 7.6-7.7) - This field defines the major node 

number of the CPSS address. 

• Slot Numbers (octets 7.8-7.9 and 7.13-7.14) - The respective octet pairs 

20 define the ingress and egress slot numbers of the call. 

• Port Numbers (octets 7.10 and 7.15) - The respective fields identify the 
ingress and egress port numbers of the call. 

. Sub-Port Numbers (octets 7. 1 1 -7.12 and 7. 16-7.17)- The respective octet 
pair fields identify the inbound and outbound sub-ports. The interpretation of these fields 
25 is protocol dependent. For cell relay based protocols, the fields define the Virtual Path 
Identifier. The first octet pair defines the ingress virtual path of the call, and the second 
octet pair defines the egress virtual path of the call. 

• Cause Value (octet 7.18) - The standard cause values are defined in 
Q.2610. Theses values define the reason for the routing failure. The cause value is 
30 associated with the port that has been most recently traversed. 
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• Diagnostics Cause Value (octet 7.19-7.20) - This field stores user defined 
(i.e., proprietary) cause values to aid network diagnostics, 

• Length of Diagnostics (octet 7.21) - This defines the length of the 
Diagnostics field. 

• Diagnostics (octet 7.22 etc) - This field contains diagnostic information 
added to the sub-structure to aid in locating the network failures. 

The Call Completed Indication (octet group 8 of Call Trace IE) denotes the 
successful traversal of a single node in the network. The sub-structure includes node and 
port information as shown below. 
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The following list details the specific fields of the Call Completed Indication 
sub-structure: 

• Call Completed Indication (octet 8.1) - This field identifies the component 
type of the sub-structure, i.e., a call completed opcode. 
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• Length (octet 8.2) - The length of the sub-structure is defined as the length 
of the entire sub-structure less the length and sub-structure identifier fields. 

• Reserved (octets 8.3 and 8.13) - The reserved fields are ignored on receipt 
and coded as zero when added to the information element. 

5 • Slot Format Identifier (octet 8.3) - The format of the inbound and outbound 

slots are specified by this field. For example "001" defines a 16-bit slot number 
consisting of an 1 1-bit shelf number and a 5-bit slot number. 

. Address Identifier (octet 8.3) - The Address Identifier indicates the type of 
node address that follows. For example "001" represents a Newbridge specific Control 
10 Packet Switching System (CPSS) address. Bit pattern "010" represents a Point Code. If 
the Address Identifier indicates a Point Code, the domain and major node number are 
replaced by a 22-octet binary number identifying the point code. 

• Domain (octets 8.4-8.5) - This field defines the domain part of the CPSS 

address. 

! 5 . Major Node Number (octets 8.6-8.7) - This field defines the major node 

number of the CPSS address. 

. Slot Numbers (octets 8.8-8.9 and 8.14-8.15) - The first octet pair defines 
the ingress slot number of the call, and the second octet pair defines the egress slot 
number of the call. 

20 • Port Numbers (octets 8. 1 0 and 8. 1 6) - The respective fields identify the 

ingress and egress port numbers of the call. 

. Sub-Port Numbers (octets 8.1 1-8.12 and 8.17-8.18) - The respective octet 
pair fields identify the inbound and outbound sub-ports. The interpretation of these fields 
are protocol dependent. For cell relay based protocols, each field defines the Virtual Path 
25 Identifier. The first octet pair defines the ingress virtual path of the call, and the second 
octet pair defines the egress virtual path of the call. 

. Selection Type (octet 8.13) - The Selection Type identifies outbound 
port/sub-port selection type, e.g., either "001" which represents the preferred route or 

"010" which represents the primary alternate route. 
30 . Flag (octet 8. 13) -This field indicates an Assigning (T) or Non-Assigning 

('0') interface. 
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In operation, call tracing is established at the exchange originating the call to 
be traced. At this point, a Call Trace IE is inserted into all calls to be traced. It is only 
explicitly enabled at the point of origin in the network and is implicitly defined to be 
active by all other nodes in the network if the Call Trace IE is found to be present. 
5 r AI L TRACE OF SUCCES SFUL CALLS 

1. Actions Required at the Originating Exchange: 
a) Initiating a Call Trace: 

When a new call is initiated, the originating exchange (i.e., switch) checks for 
the presence of a Call Trace IE in the call setup message. If not existent, a Call Trace IE 

10 without components is inserted. 

When an outgoing slot, port, or sub-port is selected, the Call Trace IE is 
modified before the setup message is forwarded. A 'Call Transited' component, 
containing the node address, ingress and egress slot/port/sub-port , is appended to the end 
of the IE. The point of origin has now been traced as the setup message at the exchange. 

1 5 A copy of the Call Trace IE with the 'Call Transited' structure is saved by the 

originating exchange. 

b) Receipt of a Connect Message: 

The originating exchange checks for the presence of the Call Trace IE in the 
Connect message. If the IE is found, its contents contain a complete trace of the 
20 successful call across the network. The information can be used by the management layer 
for diagnostic information. The IE is not forwarded to the originating interface if it does 

not support enhanced signalling. 

If the IE is not found, a copy of the Call Trace IE that was saved is added to 

the Connect message. 
25 2. Actions Required at a Transit Exchange: 

a) Receipt of a Setup Message: 

Upon successful route selection, the setup message is examined for the 
presence of a Call Trace IE. If present, a 'Call Transited' component, containing the node 
address, ingress slot/port/sub-port and egress slot/port/sub-port is appended before the 
30 message is forwarded to the next exchange while a copy of the Call Trace IE is locally 

saved. 
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b) Receipt of a Connect Message: 

The Connect message is examined for the presence of a Call Trace IE. If 
present, the message is forwarded to the preceding exchange without modification to the 
Call Trace IE. 

5 If the Call Trace IE is absent, the exchange checks for a previously saved 

copy. If such a copy exists, it is added without modification to the Connect message. The 
Connect message is then sent to the preceding exchange. In this case, a complete end-to- 
end call trace is not being performed. 

3. Actions Required at the Destination Exchange: 
10 a) Receipt of a Setup Message: 

Upon successful route selection, the setup message is examined for the 
presence of a Call Trace IE. If present, a 'Call Completed' component is appended to the 
Call Trace IE. A copy of the Call Trace IE is saved and the Setup message is then 
forwarded to the destination. The Call Trace IE is removed if enhanced signalling has not 
15 been enabled at the destination interface. 

b) Receipt of a Connect Message: 

The Connect message is examined for the presence of a Call Trace IE. If 
present, the message is forwarded to the preceding exchange without modification to the 
Call Trace IE. 

20 If the Call Trace IE is absent, the exchange checks for a previously saved 

copy. If a copy exists, it is added to the Connect message before the message is 
forwarded to the preceding exchange. 

PA IT. TR ACE FOR U NSI JCCESSFUI - CALL ESTABLISHMEN T 
Three levels of information can be provided by a node at the point of failure: 
25 a cause value, a diagnostics cause value with user defined (proprietary) diagnostics, or a 
Call Trace IE. When a failure occurs, a Release or Release Complete message is 
generated by the exchange at the point of failure. The exchange will incorporate one of 
the aforementioned levels of failure information into the message. As a result, the 
preceding node has the responsibility to process the failure information correctly. 
30 1 . Actions Required at the Originating Exchange: 

a) Detection of a call failure at the originating node: 



BNSDOCID: <WO 9833351 A1> 



WO 98/33351 



-21 - 



PCT/CA98/00029 



A Call Trace IE is inserted into the Setup message. When the originating 
exchange detects that it is unable to process with the call, a 'Call Blocked' component is 
appended to the Call Trace IE. If enhanced signalling is enabled, the Call Trace IE is 
copied to the Call Rejection message which is sent to the originating user. 
5 If the originating exchange is unable to include a copy of the Call Trace IE, 

normal call clearance procedures are followed. 

b) Receipt of a Release or Release Complete message with a Call Trace IE: 
The Call Trace IE is copied without modification to the Call Clearance 

message. The message is then sent to the originating user. The Call Trace IE contains a 
10 complete trace of the call and can be used by the management layer for local diagnostics. 

c) Receipt of a Release or Release Complete message without a Call Trace 

IE: 

The originating exchange determines if a Call Trace IE has been saved for 
this call. If the IE exists, a 'Call Blocked After Transit' component is appended. The IE 
1 5 is then copied to the Call Clearance message which is then sent to the originating user. 

d) Call Failure on receipt of Connect: 

A call failure will occur if the exchange is unable to complete the call after 

receiving a Connect message. 

If a Call Trace IE is present in the Connect message, a 'Call Blocked' 
20 component is appended. If enhanced signalling is enabled, the component is then copied 
to the Call Trace IE that is sent to the originating user. 

Otherwise, the saved Call Trace IE is copied to the Release message. A 'Call 
Blocked' component is appended to the Call Trace IE. 

If the originating exchange is unable to include a copy of the Call Trace IE, 
25 normal call clearance procedures are followed. 

2. Actions Required at a Transit Exchange: 
a) Detection of a call failure at a Transit Exchange: 
At a transit exchange, a Call Trace IE is inserted into the Setup message. 
When the originating exchange detects that it is unable to process with the call, a 'Call 
30 Blocked' component is appended to the Call Trace IE. If enhanced signalling is enabled, 
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the Call Trace IE is copied to the Call Rejection message which is sent to the originating 
user. 

If the originating exchange is unable to include a copy of the Call Trace IE, 
normal call clearance procedures are followed. 
5 b) Receipt of a Release or Release Complete message with a Call Trace IE: 

The Call Trace IE is copied without modification to the Call Clearance 
message. The message is then sent to the originating user. The Call Trace IE contains a 
complete trace of the call and can be used by the management layer for local diagnostics. 

c) Receipt of a Release or Release Complete message without a Call Trace 

10 IE: 

The transit exchange determines if a Call Trace IE has been saved for this 
call. If the IE exists, a 'Call Blocked After Transit' component is appended. The IE is 
then copied to the Call Clearance message which is then sent to the originating user. 

d) Call Failure on receipt of Connect: 

! 5 A call failure will occur if the transit exchange i s unable to complete the call 

after receiving a Connect message. 

If a Call Trace IE is present in the Connect message, a 'Call Blocked' 
component is appended. If enhanced signalling is enabled, the component is then copied 
to the Call Trace IE that is sent to the originating user. 
20 Otherwise, the saved Call Trace IE is copied to the Release message. A 'Call 

Blocked' component is appended to the Call Trace IE. 

If the transit exchange is unable to include a copy of the Call Trace IE, nonnal 

call clearance procedures are followed. 

3. Actions Required at the Destination Exchange: 

25 a ) Detection of a call failure at the Destination Exchange: 

When the destination exchange determines that it cannot proceed with a call, 
then if possible, the Call Trace IE included in the Setup message should be copied to the 
Call Clearance message. A 'Call Blocked' component is then appended to the Call Trace 
IE. 
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In all failure cases at the destination exchange, it is possible for a 'Call 
Blocked' or 'Call Blocked After Transit' component to be appended after a 'Call 
Completed' component. 

b) Receipt of a Release or Release Complete message with a Call Trace IE: 

5 At the destination exchange, the Call Trace IE is copied without modification 

to the Call Clearance message. The message is then sent to the originating user. The Call 
Trace IE contains a complete trace of the call and can be used by the management layer 

for local diagnostics. 

c) Receipt of a Release or Release Complete message without a Call Trace 

10 IE: 

The destination exchange copies the Call Trace IE that has been saved to the 
Call Clearance message being sent to the preceding exchange. A 'Call Blocked After 
Transit' component is appended to the Call Trace IE. This implies that the final Call 
Trace IE will always contain a 'Call Completed' component followed by a Call Trace 
1 5 component. 

d) Call Failure on receipt of Connect: 

A call failure will occur if the destination exchange is unable to complete the 
call after receiving a Connect message. 

If a Call Trace IE is present in the Connect message, a 'Call Blocked' 
20 component is appended. If enhanced signalling is enabled, the component is then copied 
to the Call Trace IE that is sent to the originating user. 

Otherwise, the saved Call Trace IE is copied to the Release message. A 'Call 
Blocked' component is appended to the Call Trace IE. If a 'Call Blocked' component is 
added, it may succeed a 'Call Completed' component that was already appended to the 

25 Call Trace IE. 

If the destination exchange is unable to include a copy of the Call Trace IE, 

normal call clearance procedures are followed. 

P AT J. TRACE ON CRANKBACK 
1. Actions Required at the Originating Exchange: 
30 a ) Receipt of Release or Release Complete containing Crankback and Call 

Trace IE: 
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If an alternate route is available, the Call Trace IE is copied to the outgoing 
Setup message and a 'Call Transited' component is appended. A copy of the updated IE 
is saved locally. 

If no alternate route is available, the Call Trace IE is copied to the Release 
5 message to be sent to the originating user. 

b) Receipt of Release or Release Complete containing Crankback only: 
If an alternate route is available, the Call Trace IE that was saved locally is 
copied to the outgoing Setup message. A 'Call Blocked After Transit' component is 
appended. When the alternate route is successfully selected, a 'Call Transited' 
10 component is then appended. A copy of the updated IE is again saved locally. 

If an alternate route is unavailable, the Call Trace IE is copied to the Call 
Clearance message to be sent to the originating user and a 'Call Blocked After Transit' 

component is appended. 

2. Actions Required at a Transit Exchange: 
! 5 a) Receipt of Release or Release Complete containing Crankback and Call 

Trace IE: 

At a transit exchange, if an alternate route is available, the Call Trace IE is 
copied to the outgoing Setup message and a 'Call Transited' component is appended. A 
copy of the updated IE is saved locally. 
2 0 If no alternate route is available, the Call Trace IE is copied to the Release 

message to be sent to the originating user. 

b) Receipt of Release or Release Complete containing Crankback only: 
At a transit exchange, if an alternate route is available, the Call Trace IE that 
was saved locally is copied to the outgoing Setup message. A 'Call Blocked After 
25 Transit' component is appended. When the alternate route is successfully selected, a 
'Call Transited' component is then appended. A copy of the updated IE is again saved 
locally. 

If an alternate route is unavailable, the Call Trace IE is copied to the Call 
Clearance message to be sent to the originating user and a 'Call Blocked After Transit' 

30 component is appended. 

3. Actions Required at the Destination Exchange: 
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a) Receipt of Release or Release Complete containing Crankback and Call 

Trace IE: 

At the destination exchange, if an alternate route is available, the Call Trace 
IE is copied to the outgoing Setup message and a 'Call Transited' component is 
5 appended. A copy of the updated IE is saved locally. 

If no alternate route is available, the Call Trace IE is copied to the Release 
message to be sent to the originating user. 

b) Receipt of Release or Release Complete containing Crankback only: 
At the destination exchange, if an alternate route is available, the Call Trace 
1 0 IE that was saved locally is copied to the outgoing Setup message. A 'Call Blocked After 
Transit' component is appended. When the alternate route is successfully selected, a 
'Call Transited' component is then appended. A copy of the updated IE is again saved 
locally. 

If an alternate route is unavailable, the Call Trace IE is copied to the Call 
1 5 Clearance message to be sent to the originating user and a 'Call Blocked After Transit' 
component is appended. 

The balance of the figures demonstrate three different trace scenarios that 
incorporate the aforementioned operations. Symbols used in the diagrams represent the 
20 following: 

5 User 

O Network Node 

ct Call Trace IE 

# Call Transmitted Indication 

2 5 $ Call Blocked Indication 

@ Call Blocked After Transit Indication 

! Call Completed Indication 

() ' Contains' 

Figure 3 illustrates the Call Trace feature activated for a successful call. The 
30 indicated messages are those which are relevant to the Call Trace feature. 
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The Setup message originates at user a and progresses through the network 
along nodes A, B, and E before arriving at user b. User b responds to Setup Message with 
a Connect message to indicate that the call has successfully completed. 

Figure 4 provides a slight variation to the previous figure. In this instance, 
5 the Call Trace feature is activated for a successful call with one routing failure at a node. 
Again, only messages relevant to the Call Trace feature are shown. 

The Setup message originates at user a and traverse a path along nodes A, C, 
and B. At node B a routing failure occurs. The Setup message then trans verses a path 
from B though nodes C, D and E until a successful call completion is reached at user b. A 
10 Connect message is then sent back through nodes E, D, C, and A to user a. 

Figure 5 depicts a call failure that is the result of multiple node failures. This 
scenario assumes that route D-E is Out of Service (OOS) and cannot be used to route the 
call. 

The call is initiated from user a through node A. The message progresses by 
15 the preferred route to node B. Node B rejects the call due to a resource problem, but does 
not include a Call Trace IE. The call progresses to node D when the alternate route A-D 
is selected. Node D also rejects the call. The final Call Trace IE in the Release message 
from node D contains information of the 2 node failures. 

Those skilled in the art will recognize that various modifications and changes 
20 could be made to the invention without departing from the spirit and scope thereof. It 

should therefore be understood that the claims are not to be considered as being limited to 
the precise embodiments set forth above, in the absence of specific limitations directed to 
each embodiment. 
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We claim: 

1. A method of detecting and diagnosing faults in a network having a plurality of . 
nodes through which switched virtual connections can be established, characterized in 

that it comprises the steps of: 
5 a) recording all attempts at establishing routes through the network; and 

b) analyzing the attempted routes to identify the source of a failure. 

2. A method as claimed in claim 1, characterized in that diagnostics data are gathered 
for each attempted route. 

3. A method as claimed in claim 2, characterized in that said diagnostics data include 
1 0 the location and nature of said failure. 

4. A method as claimed in claim 2, characterized in that said diagnostics data are 
included in a message propagated through the network. 

5. A method as claimed in claim 4, characterized in that said diagnostics data are 
included in an information element (IE) field forming part of said message. 

15 6. A method as claimed in claim 1 , characterized in that for each attempt to establish 
a route through the network, diagnostics data pertaining to each switch and trunk group 

traversed is recorded. 

7. A method as claimed in claim 1 , characterized in that said network is an ATM 
network, said nodes comprising ATM switches. 

20 8. A method as claimed claim 1 , characterized in that said switched connections are 
switched virtual channel or soft permanent virtual channel connections. 

9. A method of detecting and diagnosing faults in a network having a plurality of 
nodes through which switched virtual connections can be established, comprising the 
steps of : 
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a) entering a diagnostics mode for a given user when a suspected fault is detected; 

b) attempting to establish a virtual connection originating at said given user 
through the network to a destination user via a plurality of alternate routes; 

c) collecting diagnostics data for each attempted route through the network to said 

5 destination user; and 

d) analyzing the said diagnostics data to identify the source of a failure. 

10. A method as claimed in claim 9, characterized in that said diagnostics data is 
propagated through the network in a message. 

11. A method as claimed in claim 10, characterized in that said diagnostics data 
1 0 include the nature and location of said failure. 

12. A method as claimed in claim 10, characterized in that the call diagnostics data are 
returned the originating user. 

13. A method as claimed in claim 9, characterized in that said diagnostics mode is 
automatically deactivated after a predetermined number of connection setups originating 

15 from said given user. 

14. A method as claimed in claim 9, characterized in that said diagnostics data are 
carried in an information element of a message. 

15. A method as claimed in claim 14, characterized in that said information element is 
a call trace element. 

20 16. A method as claimed in claim 1 5, characterized in that said call trace element 
includes a call transited field and a call blocked field. 

17. A method as claimed in claim 1 6, characterized in that said call transited fields 
and said call blocked fields include data identifying at least domain and node number of a 
node encountered on an attempted virtual connection. 
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18. A method as claimed in claim 1 7, characterized in that said call transited and call 
blocked fields also include data identifying slot number and port number of an 
encountered node. 

19. A method as claimed in claim 1 7, characterized in that said call blocked field 
5 contains data relating to the nature of a routing failure. 

20. A method as claimed in claim where said nodes contain hop-by-hop routing 
tables. 

21. A packet switched data communications network, comprising: 
a) a plurality of interconnected network nodes; 

j 0 b) a plurality of users connected to at least some of said network nodes; 

c) means for attempting to establish virtual connections between users over a 
plurality of alternate routes through said network; 

d) means for recording, in a diagnostic mode, attempts at establishing routes 

through said network; and 
1 5 e) diagnostic means for analyzing said recorded attempts to identify the source of 

a failure. 

22. A packet switched data communications network as claimed in claim 2 1 , 
characterized in that said nodes include service cards having a call control unit and a 
signalling stack for setting up a virtual connection, and a service card managing a virtual 

20 connection collects diagnostics information for said recorded attempts at establishing 
routes through said network. 

23 . A packet switched network as claimed in claim 2 1 , characterized in that each node 
comprises means for returning to an originating user, in the diagnostic mode, detailed data 
relating to the progress of an attempted connection through that node. 
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24. A packet switched network as claimed in claim 23, characterized in that each node 
comprises means for inserting said detailed data into an information element of a message 
returned to an originating user. 

25. A packet switched network as claimed in claim 24, further comprising a Node 
5 Management Terminal Interface adapted to analyze said detailed data. 

26. A packet switched network as claimed in claim 2 1 , characterized in that said 
switches are ATM switches. 

27. A method of detecting and diagnosing faults in a network comprising a plurality 
of switches, characterized in that details are collected in call processing messages for each 

10 switch and physical trunk visited plus rejection causes for every attempted route during a 
call setup phase. 

28. A method as claimed in claim 27, characterized in that the collected information is 
returned in the call processing messages back to the source switch which in turn presents 
this information to network operators. 
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